AWSアクセスキー・ローテーションのススメ

AWSアクセスキー・ローテーションのススメ

Clock Icon2014.07.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

よく訓練されたアップル信者、都元です。AWSにおけるクレデンシャルには大きく「管理コンソールにログインするためのパスワード(Sign-In Credentials)」と「APIアクセスを行うためにAPIキー(Access Credentials)」の2種類があることをご紹介しました。そして、前者Sign-In Credentialsのセキュリティを強固なものにする手段として、MFAの活用についてもご紹介しました。

本当は怖いアクセスキー

しかし実は本当に怖いのは、後者Access Credentialsのセキュリティです。アクセスキーはMFAによる保護に向いていません。設定を工夫すれば、「MFAによる認証を経なければアクセスキーを使えないようにする」ことも可能です。しかし、一般的には「プログラムが使う認証情報」であることが多いため、MFAの認証コードがなければAPIが叩けない、というのは受け入れられないケースが多々あります。

さらに、こちらも当ブログにて警鐘が鳴らされている件ですが、アクセスキー *1があれば管理コンソールログイン時のMFAを解除できることが知られています。もちろん、ログインパスワードの変更もできてしまいますね。

このようなリスクを回避するため、AWSは公式ドキュメントにおいて、90日毎にアクセスキーのローテーションを推奨しています。何とも原始的ですが、やらないと後が怖いですよ。

キーローテの方法

まず、自分が管理するIAMユーザのアクセスキーについて、発行日時を確認しましょう。IAMのManagement Consoleでユーザを選択し、下部のタブで「Security Credentials」を選択します。Access Keysの項で、キーの発行日時が示されています。

2014-07-09_1734

なんと、発行から1年半近く経っていますね。これはいけません、ということでローテーションを行いましょう。

ちなみに、アクセスキーは1つのIAMユーザにつき2個作成できます。なぜ1個ではなく5個でもなく、2個なのでしょうか。その理由はどこかに書いてあるわけではありませんが、私は「キーローテーションのためだ」と思っています。前述の通り、アクセスキーはプログラムから利用されることが多い認証情報です。つまり、ローテートをしようとしている、まさに今、絶え間なくキーが使われているかもしれません。新しいキーを得ると同時に古いキーが無効になってしまったら、稼働中のシステムに障害が発生してしまうかもしれません。

それを避けるために、一時的にアクセスキーを新旧2つとも有効な状態で使えるように、という配慮で「2個作成できる」ようになっているのだと思います。アクセスキーは、2個作れるからといって、キーローテーション以外の何らかの目的で、便利に使うべきではありません。

ではまず、ローテ先の新しいアクセスキーを発行してみましょう。画面中の「Manage Access Key」ボタンをクリックします。

2014-07-09_1734-1

このポップアップで、「Create Access Key」をクリックします。

2014-07-09_1735

上記のような表示が出たら、Download Credentialsボタンでcsvファイル形式でダウンロードするか、またはShow User Security Credentialsをクリックして画面に表示するか、でアクセスキーを取得します。

2014-07-09_1735-1

ちなみにcsvをダウンロードせずにClose Windowをクリックすると上のような警告が出ますが、きちんと情報を取得できていれば問題ありません。

2014-07-09_1736-1

というわけで、上記の通り新しいアクセスキーを手に入れることができました。

この状態で、アクセスキーを新しいものに差し替えてください。アプリケーションの設定画面、設定ファイル等、利用方法によって違っているはずですが、古いキーは削除によって使えなくなるため、全てを書き換えてください。

続いて古いアクセスキーの削除、と行きたいところですが…。残念ながら「どこでこのアクセスキーが使われているのか把握しきれていないので、全てのキーが差し替えられているか不安だ」ということもあるかもしれません。これはセキュリティ的には非常に残念な状態です。その場合は以後気をつけるということで、まずは削除 (Delete) ではなく無効化 (Make Inactive) を行ってみるのもひとつの手です。アクセスキーを無効化してしばらく様子を見ておき、関連システムがエラーを出さなければ大丈夫でしょう。万一エラーが発生するような事態となったらすぐにActiveに戻し、キーの機能を復旧させることができます。

ただ上記は「試しに障害が起こるかどうかやってみる」という非常に乱暴な手です。運用中のクリティカルなシステムには使えません。…運用中のクリティカルなシステムでアクセスキーをどこで使っているか分からないなどという事態については、まず深く反省しましょう。次からはやっちゃいかんよ。

こうなったらば、残った救済策はCloudTrailくらいしか浮かびません。CloudTrailのログからは、いつ・どのAPIが・どのアクセスキーを使って呼ばれたのか、といった詳細な情報が得られます。一定期間ログを取得して古いアクセスキーが使われていないかチェック、使われているのであれば呼び出し元IPアドレス等から利用場所を突き止める、というような手はずになります。大変ですが、頑張って。

さて、以上で晴れて古いアクセスキーは不要になったはずなので、削除します。先ほどのポップアップで Delete のリンクをクリックし、下記のような確認を経れば、晴れてローテートの完了です。

2014-07-09_1737

そもそも

通常はIAM Roleによる一時キーを使うべきです。そうすればキーローテーションは自動で行われますので、このような苦行の必要はありません。IAMユーザのアクセスキーは、下記のような特殊な場面以外で使うべきではないと思っています。これ以外で、IAMユーザのアクセスキーを使っていなければ、キーローテの手間もそれほど大きいものではないでしょう。

  • システムがEC2ではなく、オンプレミス環境で動いている(つまりIAM Roleが使えない)システムが利用する場合。
  • 開発環境等、ローカルマシンで動いているアプリケーションからAPIをコールする必要がある場合。
  • aws-cli等、オペレータがアドホックに利用するユーティリティで利用する場合。
  • 一時キー(Temporary Security Credentials)をサポートしていないAPIを呼ぶ必要がある場合。(参考ドキュメント

また、そもそも使っていないアクセスキーであった場合、ローテートするというよりも単純に削除してしまうのが最もセキュアです。これは本当に必要なキーなのか、この機会にじっくり考えなおしてみてはいかがでしょうか。

脚注

  1. IAMの権限を持っているもの。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.